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(57) Abstract: An apparatus and method of effecting an elecU-onic transfer of funds between a payer account and a payee account 
wherein the payer account and the payee account are each held at a financial institution that is a member of a financial settlement 
network. A payer (10) transmits a purchase order (200) to a payee (102) via a business hub (103), which purchase order identifies 
the payer. The payee, in response to receipt of the purchase order, transmits an invoice (201) to the payer via the business hub, 
which invoice identifies the payee account for crediting funds for the purchase. The payer, in response to receipt of the invoice and 
subsequent to approval of the purchase, transmits a secured payment instruction (202) to a payment gateway (104), which payment 
instruction identifies the payer account for debiting- The payment gateway, in response to receipt of the secured payment instruction 
and subsequent to ensuring authenticity (203) of the payment instruction, creates a payment request message (204) for the payer* s 
financial institution (106) and passes the payment request to the settlement network (105). The payment gateway (104), in response 
to a payment authorisation message (205) from the payer's financial institution, notifies payment approval (206). The financial 
settlement network (105) facilitates settlement (209) of the U-ansfer on a net basis between the payer's financial institution and the 
payee's financial institution. 
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AN ELECTRONIC FUNDS TRANSFER SYSTEM USING CREDIT CARD 
SETTLEMENT AND FINANCIAL NETWORK INFRASTRUCTURE 

5 BACKGROUND OF THE INVENTION 

(0 Field of the Invention 

This invention relates to an electronic payment system that facilitates 
10 integration with existing financial services networks to implement domestic and 
international funds transfer transactions, be it business to business transfers, business to 
consumer transfers and vice versa, as well as consumer to consumer transfers. In 
particular, although not exclusively, the invention relates to a method and apparatus for 
effecting electronic funds transfers, akin to telegraphic transfers, which utilize a global 
15 public communications network (such as the *Tntemet") and business hubs for 
integrating with credit card settlement arrangements and financial networks utilised by 
financial institutions. Multiple currency transactions may also be accommodated by 
the electronic payment system of the invention. 

20 (ii) Discussion of the Background Art 

Existing arrangements for initiating funds transfers typically involve a business 
or consumer providing instractions to the financial institution via a branch, either in 
person or in writing, or directly via financial institution supplied proprietary work 

25 stations located in a business's offices. Manual preparation of instiuctions is slow and 
inefficient, whilst the cost for both the busmesses, consumers and the financial 
institution for installation and maintenance of proprietary work stations can be 
prohibitive. The consumers and businesses encompass parties that wish to trade in 
goods and services, as well as anyone who may wish to remit funds to another party or, 

30 as the context may require, the relevant authorised si^atories of those parties. 

Currentiy, when financial institutions make cross border payments on behalf of a 
paying party ("payer"), that party's payment instruction is typically manually converted 
by the payer's financial institution into a message that is then sent to the recipient 
35 party's ("payee") financial institution. Such messages must generally be assembled in 
accordance with a specific protocol, such as SWIFT, that is generally recognised and 
accepted by banks and other financial institutions. If the payer's financial institution 
and the payee's financial institution do not maintain a relationship vidth one another, an 
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"^^ SWIFT financial network acts to route messages between member fc^^ 
5 mswunons. typicaUy banks. Some validation of data is perfonned, however this 
vahdafton does not usually include validation of information relating to the transaction 
such as the payer account number with the payer's financial institution, as financial' 
networks like SWIFT do not maintain such infomaation. Member financial institutions 
settle agamst each other for individual transactions, if correspondent financial 
10 mstitutxons are also involved, then multq,le settlement "legs" are required. Settlement 
needs to be performed for each individual transaction, which adds to service costs and 
possible delays in transmission of fimds. 

When a financial institution wishes to offer a variety of foreign currency 
15 services, it must maintain individual relationships in each location for every currency 
they wash to offer. A foreign currency payer is also exposed to the risk of unfavourable 
exchange fluctuations when setflement occurs some days after payment is authorised. 



20 



BRIEF SUMMARY OF THE INVENTION 
(i) Object of the Invention 



It is an object of the present invention to provide an apparatus and method for 
effecting electronic fimds transfers, akin to telegraphic transfers, but which delivers a 
25 more rapid and economical mefeod of processing payments, when compared with 
traditional fimds transfer arrangements. 

It is another object of the invention to provide an apparatus and method for 
effecting electronic fimds . transfers which may be • implemented quickly and 
30 conveniently through integration with existing financial networks^ particularly 
networks and arrangements utilised for credit card settlement purposes. 

It is a fiirther object of the invention to provide an apparatus and method for 
effecting electronic fimds transfers which may substantiaUy reduce foreign exchange 
35 risks. 



It is a still further object of the invention to provide an apparatus and method for 
effecting electronic funds transfers which allows remote, secure electronic initiation by 
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payers and which facilitates on-line tracking and reconciliation of payments. 



It is a yet further object of the mvention to provide an electronic funds transfer 
system which ameliorates and more appropriately shares the risks associated with 
5 undertaking financial transactions via the Jhtemet 

(ii) Disclosure of the Invention 

In . a first form, relating to a typical commercial transaction, the invention 
10 resides in a method of effecting an electronic transfer of fimds between a payer account 
and a payee accoxmt wherein the payer account and the payee account are each held by 
respective parties at financial institutions associated with a financial settlement 
network; said method including the steps of 

(a) a payer providing a purchase order to a payee, which purchase order 
15 identifies the payer to the payee; 

(b) a payee, subsequeiit to receipt of the purchase order, providing an 
invoice to the payer, which invoice identifies the payee account for crediting funds in 
the transfer; 

(c) the payer, in response to receipt of the invoice and subsequent to 
20 approval of the transfer, transmits a secured payment instruction to a pajmient gateway, 

which payment instruction identifies the payer account for debiting; 

(d) the payment gateway, in response to receipt of the secured payment 
instruction and subsequent to ensuring authenticity of the payment instruction, creates a 
payment request message for tije payer's financial institution and passes the payment 

25 request to the financial settlement network; and 

(e) the payment gateway, in response to a payment authorisation message 
from the payer's financial institution, notifies payment approval to the payer and passes 
a settlement message to the financial settlement network, whereby the settlement 
network facilitates settlement of the transfer on a net basis with the payer's financial 

30 institution and the payee's financial institution. 

Preferably the payer provides the purchase order to the payee by transmitting 
said purchase order via a business hub or business portal. 

35 Preferably, the payee provides the invoice to the payer by transmitting said 

invoice via a business hub or business portal- 



Suitably parties are each allocated a unique identifier that is registered with the 
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payment gateway. 

T''"' '""^ ^^^^^^y -^^^---d with the pa^oxient 

gateway m relation to a at least one account with a financial institution 

^ Ptoses and/or a debit 

account for purchasing purposes, as required. 

a trusteTllo^V" "^^^^^^^ 
a trusted authonty for security purposes. 

10 

Suitably financial institutions are each allocat^ a unique identifier that is 
registered wxth the payment gateway, m the case of a bank, a bank identification 
number (BIN) may fomi the financial institution identifier. 

Preferably the purchase order includes the payer's identifier and a description of 
goods and/or services desired to be purchased. 

Suitably the invoice includes die payee's identifier and the payee account is 
selected from a merchant account registered with the payment gateway. 

Preferably the payer creates a payment instruction by accessing the business 
hub. selecting a payer account from the debit accounts registered with the payment 
gateway and mdicating the currency and amount for payment 

The payer may select a foreign exchange rate from a board rate specified by the 
financial institution. 

An approved signatory desirably applies a security means to the payment 
instruction prior to transmission to the payment gateway. 

Suitably payers maintain a signing matrix of ^proved signatories on the 
payment gateway for each registered debit account. 

Preferably the payment gateway ensures authenticity of the payment instmction 
35 by checking the security means against the approved signatories for the registered debit 
account. 



20 
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30 



The payment request is preferably created by reformatting the information 
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payment .ecvces » payers ™d payees ™ a. lea^ one busmess hub or busine^ porT 

' b...ei:rr::,r::r'^""'^"^'~ 

Mos, preferably the payment web server includes a payment secmity 

xo b™::.^"' ''^""^ ^"-"'^^^ '° ™= bnb : 

Suitably the payment security anangement includes a security proxy for 
secutmg .nfommtion identifying the payer accomit. the payee account and the fimds for 
transfer. 

15 

Preferably the payment factory includes an administration module for 
registenng parties that wish to effect funds transfer, by allocating a miique identifier to 
each party. 

20 Most preferably the payment factory includes a payment engine for processing 

the secured payment instructions and creating messages formatted for the financial 
settlement network. 



Preferably the payment web server communicates with said at least «^ 
25 business hub and with said hubs and portals and with registered parties via a pubU< 
communications network, such as the Internet 



one 

LC 



Preferably the payment factory further includes interface means for 
communicating the authorisation request messages and settlement messages to the 
30 financial institutions via the financial settlement network. 

Suitably the financial settlanent network includes credit card networks. 

Preferably the payment factory further includes a security server for 
35 authenticating communicatioris using predetermined securing means. 

Suitably the predetermined securing means for communicating via the public 
communications network mclude digital certificates and private, keys allocated to 
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contained in the payment instruction, including the payer account and an 
identifier corresponding to the payer's jBnancial institution. 

The payment request may be an SMS 0200 financial transaction request 
5 message sent to the financial network which includes a credit card settlement network. 

In preference, the financial network transmits settlement messages to financial 
institutions at least daily. 

10 The settlement message may be a Base II settlement message. 

Upon settlement, the payer and optionally the payee, may be notified of tiie 
fimds transfer. 



15 Most preferably, the financial network settles the payment transaction on a net 

basis for both domestic and international transactions, through at least one settlement 
financial institution. 

An agent financial institution will facilitate foreign currency settlement with tiie 
20 payer's fmancial institution and/or the payee's financial institution, as required 

In another form, suitable for electronic commerce, the invention resides in an 
electronic fiinds transfer apparatus for effecting transfer of fimds between a payer 
account and a payee account wherein the payer accoimt and the payee accoxmt are held 

25 by respective parties at financial institutions that are associated with a financial 
settlement network, said apparatus comprising: 

(a) a payment gateway having a payment web server and a payment factory, 
wherein the payment web server communicates with the parties, and the payment 
factory commxmicates with a plmaJity of financied institutions; 

30 (b) the payment web server is operative to provide payment services to 

parties, wherein payers transmit secured payment instructions to the jpayment gateway 
subsequent to receipt of invoices from payees, which invoices identify the payee 
account for crediting in the transfer; and 

(c) the payment factory is operative to process said secured payment 

35 instructions, which instructions identify tibie payer account for debiting, by creating 
messages for the financial settlement network requesting authorisation of payment firom 
the payer account and initiating settlement of the transfer on a net basis with respective 
financial institutions of the payer and tiie payee. 
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n«v™ l'^^^"^^^^ ^^^^^ i^^J^des an integrated module for offering 

payment services to payers and payees via at least one business hub or business portal. 

^ h„.- ^Tu^^ transmitted by payees to payers via said at least one 

busmess hub or business portal. 

Most preferably the payment web server includes a payment security 
anr^gement for securing infonnation supplied to said at least one business hub or 
10 busmess portal. 

Suitably the payment security arrangement includes a security proxy for 
securmg information identifying the payer account, the payee account and the funds for 
transfer. 

15 ' 

Preferably the payment fectory includes an administration module for 
registenng parties that wish to effect funds transfers by allocating a unique identifier to 

each party. 

20 Most preferably the payment factory includes a payment engine for processing 

the secured payment instructions and creating messages formatted for the financial 
settlement network. 



Preferably the payment web server communicates with said at least _ 
25 business hub and with said hubs and portals and with registered parties via a publ; 
communications network, such as the Internet. 



one 

ic 



Preferably the payment fectory finther includes interface means for 
communicating the authorisation request messages and settlement messages to the 
30 financial institutions via tiie financial settlement network. 



Suitably the financial settlemoit network includes credit card networks. 

Preferably the payment factory furflaer includes a security server for 
35 authenticating communications using predetermined securing means. 

Suitably the predetermmed securing means for communicating via the public 
communications network include digital certificates and private, keys allocated to 
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registered parties by a trusted authority, such as a certification authority. 

Desirably, the financial settlement network transmits settlement messages at 
least daily to financial institutions in the network. 

5 

The electronic fimds system of the invention provides several advantages over 
prior art payment systems such as SWIFT. The party registration process reduces error 
rates when creating and receiving payments because the system can perform party 
validation up-front as each transaction is created. This validation is reinforced by the 
10 financial institution authorisation rhessages that arq obtained when each payment 
instruction is approved. Thus lower error rates, which call for repairs in the prior art 
systems, results in lower processing costs for the system of the invention. 

The invention also provides a direct interface for parties of all financial 
15 institutions in the credit card settlement network. The financial institutions do not need 
to spend money and expend resources to develop proprietary work stations to support 
parties. 

Parties can operate different accounts with their different financial institutions 
20 through one web application, and there will be economies of scale if a majority of 
associated financial institutions adopt the system. Party set up and maintenance costs 
to financial institutions of the web appUcation is lower compared with financial 
institution proprietary systems. 

25 Payer payment instructions are converted by the systrai into a settlement 

message that can be carried over the credit card network. No mamial effort is required 
by financial institutions which results in finther cost savings. The aredit card network 
conveniently provides routing and processing for business to business transactions. 

30 Many financial institutions already have the necessary infi:astracture to support 

credit card networks. Financial institutions may settle on a net basis instead of on a per 
transaction basis, which allows lower balances to be maintained with settlement 
financial institutions. 

35 Financial institutions require a relationship with one domestic or national 

settlement (NNS) financial institution and with one international settlement (INS) 
financial institution. Credit card networks have an estabUshed base of financial 
institutions together with business and individual consumers, thus providing economies 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram showing the objects involved in an electronic ftmds transfer 
m accordance with a first embodiment of the invention; 

FIG. 2 is a diagram illustratirig the steps in a method of electronic funds transfer 
of the first embodiment; 

FIG. 3 is a diagram depicting the electronic funds transfer apparatus of the firet 
embodiment; 

FIG. 4 is a diagram illustrating security arrangements for the electronic transfer 
15 system of the first embodiment; and 

FIGS. 5A and 5B are diagrams, that together. Ulustrate details of the 
architecture of an electronic funds transfer apparahis of a second embodiment. 

20 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The diagram m FIG. 1 illustrates one example of the entities and components 
mvolved in the operations of the electronic fiinds transfer system 100 of a first 
embodiment of the invention. In the example there is a payer 101, such as a buyer, that 

25 wishes to acquire certain goods or services and a payee 102, such as a seller, that is 
offering goods and services for sale. Payers and payees may be introduced to one 
another by way of a business hub or business portal 103, which is associated with a 
payment gateway 104. In the example, the portal 103 allows busmesses to offer goods 
and services for direct electronic ordering by other busmesses who have certam 

30 requirements and have utQised the portal to search for and obtain details of the required 
goods/services. 



The payer 101 and payee 102 are able to communicate with the portal 103 and 
the payment gateway 104 via a public commxmications network 109, such as the 
35 Internet. The system 100 will typically allow for additional business portals 105 and 
106, which like portal 103, will communicate with tibie payment gateway 104 via tiie 
Internet. Whilst only one payer and one payee is shown in the diagram for reasons of 
clarity, it will be appreciated that such business portals or hubs \nU each provide 
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facilities allowing many payees to interact with many more potential payers. The 
portals may be aligned with certain related business sectors for example. 

The payment gateway 104 provides an interface into a financial settlement 
5 network 105, here a credit card network, which utilizes certain conmnmications 
protocols to Unk a payer financial institution, such as payer bank 106, a payee financial 
institution, such as payee bank 107 and an agent financial institution, such as agent 
bank 108. In the embodiment, the financial network includes a private seciure 
commimications network linking member financial institutions that is maintained for 
10 the purposes of credit card transactioris, such as VISANET. Again only the payer bank 
106 (of payer 101) and the payee bank 107 (of payee 102) are illustrated, although 
many financial institutions will be members of the relevant credit card association. In 
other embodiments, the payment gateway processing capability, or selected modules of 
that capability, may be situated at a selected financial institution. 

15 

In order to use the electronic fiinds transfer system 100 of the embodiment, each 
party may be set-up with a profile which is unique for each party, irrespective of 
whether the party is a payer 101 or a payee 102, or both. This will at least include 
details of a payer account 111, whereas a payee account 112 may be included as 

20 required. Parties which are business entities may also establish user groups in order to 
define fimctionality access and data access rights to the system , for individual users 
within the business entity. Each business party may also have access to multiple 
accoxmts fi-om multiple financial institutions, thus financial institution accounts are 
mapped to specific parties. Accordingly, set up procedures also involve, for the parties 

25 that are business entities, designating signatories and assigning each account to an 
approved signatory. 

In one arrangement, payer accounts are associated with a signing matrix 
wherein signing authorities of parties that are business entities are assigned to specific ; 

30 access levels within the fimds transfer system. Digital signatures, which are specific to 
an individual, whether a payer or employee of a payer business entity, are issued to 
account signing authorities. The digital signatures issued to individuals are useable 
with multiple accounts, but are typically financial institution specific. Individual users 
can tiien activate their digital signatures through a trusted certificate authority 110. 

35 Suitably, each party is made responsible for all party internal security matters. 
Authorised signatories of the electronic system will perform due diligence checks 
duru;ig processing (as explained further below). However, liability for pre-processing 
fraud in this arrangement is typically home by the payer. 
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30 



35 



In order to set up arrangements the financial institutions need to establish card 
accounts for each payer, assigning the card account numbers to the payer, t^y l 

r^^l'^r ^""^^^^ '^^^ " -tituti^ 

Tk. trus^ authonty 110 will desirably be independent, external and will bear liabUity 

registra^on and identification of signing authorities, through a security aoangem^^ 
^ h as a digital signature mechanism. A. database associated with the p!ymen 
ga way 104 stores necessary party, account and financial institution info Jtio^ as 
will be descnbed m fiirther detaU herein below. 

A method of effecting electronic fimds transfer of the first embodiment will 
now be described in relation to FIG. 2. In the embodiment the payer party will have 
been registered with the payment gateway 104. The payer 101 has. in this example 
previously logged onto a busmess hub, such as business to business (B2B) portal lOs' 
through the Internet and has decided to purchase certain goods or services offered by 
payee 102. The payer 101 sends a purchase order 200 to the payee via the B2B portal 

103. In response to receipt of the purchase order, the payee 102 creates an invoice 201 
which Identifies a payee account for 112 crediting of fimds for the purchase The 
account ,s suitably chosen fi-om a list of payee accounts registered with the gateway 

104, thus eliminating the possibility of incorrect account information which might 
delay settlement. The invoice is sent to the payer via the B2B portal 103. It will be 
appreciated that purchase orders and invoices may be provided, in other variants of the 
mvention. on paper by mail or perhaps communicated verbally by telephone. 

Upon receipt of the invoice 201, the payer 101 or an appropriate signatory in the 
payer business organisation, checks and approves the purchase by creating a payment 
mstruction 202. The payer wUl select which currency and account number to make the 
payment fiom, before the invoice is preferably batched with others for approval. The 
B2B portal may also aUow the payer, or managers or other signatories of payers that 
are business entities to log on via the payment gateway to review and separately 
approve payments on an individual or batch basis. The payer can also set up rules for 
foreign exchange rate to be either taken fiom the prevailing board rate or to request a 
treasury quote. 

Although the payer continiies to interact with the B2B portal 103, the payment 
mstmction, when complete, is transmitted to the payment gateway 104 together witii 
information identifying the payee and the transaction. The information with Jhe 
payment instruction, which is encrypted and digitally signed by .the payer, suitably 
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includes the payee's name, account number, invoice number, purchase order 
number, payment amount and currency, as supplied by the B2B portal 103. It should 
be noted that for payers that are business entities, there may be multiple signatories 
which can be accommodated by the signing matrix described below. 

5 

The payment gateway 104 decrypts the payment instruction 202 and checks the 
mstniction against the payer's signing matrix. This suitably involves authentication 
203 with the trusted certificate authority 110. If the digital signature is authenticated, 
the payment instmction 202 is immediately reformatted into a payment authorization 
10 request message 204 suitable for the financial network 105. In the method of the 
embodiment, a Base I 0100 message containing the payer (issuing) financial institution 
ID is created and passed to VISANET network. In an alternative arrangement, an SMS 
0200 message may be created. 

The financial network 105 then routes the payment request message 204 to the 
payer bank 106. The payer bank will check for available balance before returning a 
payment authorisation message 205, such as a Base I QUO message or an SMS 210 
message, via the financial network 105 to the payment gateway 104. 

The payment gateway 104 will re-format the payment authorization message 
and update the B2B portal information about the transaction, for example flie payment 
authorization code provided with the 0110 (or alternatively SMS 0210) response may 
be appended to the payment request, to enable payer and payee to view Hxc status of tibie 
payment through the Intemet. The payment gateway 104 will send a payer notification 
206a to the payer that the payment has been approved through the B2B portal or 
directly via the Intemet. Payers 101 can be notified either on a real time or on a batch 
basis. The payment gateway can, if required, provide additional data to enable the 
payer to update their enterprise resource planning (ERP) or corporate host system. 

Similarly, the payment gateway 104 will send a payee notification 206b to the 
payee 102 that the payment has been approved through the B2B jportal or the Intemet. 
The payees can be notified on a real-time or batch basis. The gateway may again 
provide data to enable the payee to update their ERP or corporate host system, as 
required. 



On at least a daily basis, the credit card settlement network, VISANET in the 
example, will settle the transactions on a net basis for domestic and international 
transactions. An agent financial institution 108, such as a major intemational bank. 
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An overview diagram of an electronic funds transfer apparatus 300 nf » « * 
S embodiment of the invention is illustrated in FIG 3 The f . 
payment gatewa, 301, ..e. — a^^".,^ ^xem 1^^^^^ 
authon^ systems 302. consumer/business (party) computer s^Zs ^B^^L ;:!: 
hubs 304 vza the Internet 305. Tt. payment gateway 301 also communica^:^; 

VISANET network 306 and the value added networlc (YAM) 307. T,. exenTpll 
federal system mstallations include those for a issuing ban. 308 and for an 

15 the ""TT -corporates a payment web server 310 which hosts 

15 he web front end to al, services offered by the system of the embodiment, including 
the core payment service and other value added services. The functions pxx>vided by 
the web server 3 1 0 include: " viuca oy 

supporting payer initiation of payment and entry of payment instruction 
mformation, with batch payment for payer if required; 
20 • supporting multi-authorisation matrix signing for payers that are 

business entities; 

allowing a payer to select from a list of pre-registered paymg financial 
institution and accounts for payment; 

allowing a payee to indicate through the B2B hub the crediting account 
25 firom a list of pre-registered acquiring financial institution and accounts; 

supporting secured inquiry and n^ort down-load for payer and merchant 
through the Internet; and 

inquiry and down-load of system reports on periodic or npon-request 
basis for merchants, payers, e-commerce hubs and financial institutions, 
including reports on approved payments, declined payments, excq)tions.' 
transaction details, transactions summary. 



30 



The payment web server 310 also includes an integration module 311 for 
embedding of pages in the business to business (B2B) hubs 304. This module offers 
35 web pages, applets to offer payment services through the B2B hub web fiont end. The 
web services though hosted on the payment web server 310 can be integrated into a 
B2B hub's web pages 312 giving a consistent look and feel. This will aUow B2B hubs 
to offer an electronic fimds transfer payment service quickly and with minimum 
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integration effort. The integrated module 311 also includes a payment security 
proxy sub-module 3 13 to enciypt sensitive information such as account number at the 
pomt of data entry. Such encrypted confidential information may suitably only be 
decrypted by an integration package at the issuing financial institution. This assures the 
5 privacy of the confidential infomiation during transmission and storage of data between 
the point of entry to the point where the information is required 

The payment gateway 301 also includes a payment factory 314 that is the 
processing module of all electronic funds transfer services and functions. The payment 
10 factory has several sub-modules including a security seryer 3 1 5, a payment engine 3 1 6, 
a payment log 317, an administration sub-module 318, a 'Value added services'' sub- 
module 319, along with a VISANET interface 320 and a value added network (VAN) 
interface 321 for the respective networks, 

15 The secmity server 315 provides digital certificate authentication for point to 

point connections between the payment gateway 301, B2B hubs 304 and issuing 
financial institutions 308; digital certificate authentication for payer parties; and 
cryptographic services to decrypt the data passed firom payer entry, including payer ID, 
invoice number, amount, issuing financial institution, payer account number, acquiring 

20 financial institution and payee account number. 

The payment engine 316 this module carries out all payment related processing. 
The payment engine manages payer authentication flow, issuing authentication requests 
through VISANET or initiate the authentication processiag fiinction within the engine. 
25 The payment engine manages payrnent message flow, including the sequence and state 
of payment message processing, iuitiation and routing. Payment message formattiag is 
also handled by the payment engine, including payment message interpretation and 
iuitiating responses to parties. The payment engine manages a signing-matrix database 
and perforaxs signing-matrix verification. 

30 

The payment log sub-module 317 logs all payment activities including payer 
inputs, payment messages and response to parties 303 for accoimting and tracing 
puiposes. The administration sub-module 318 handles both registration and profile 
configuration for payers and payee (or merchant) registration and profile configuration. 
35 Application administration for payment gateway operators (such as banks and other 
financial institutions) is also facilitated, including user access, administration, security 
configuration and similar *Tiouse keeping" fimctions for operators. The logging of 
administration activities of payers, merchants, and operators is also conducted. 
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r^.r^'^l ^^"^ ""^"^ sub-module 319 provides a variety of inquiry and 

^ortmg func^ons including payment inquiry, sununary and detailed payme^lot 

(ERP) mtegration. loyalty points scheme management and consumer profiling. 

formatTrT"/^^ fl''^" -P^--^ -ssage 

" ' ^"^"'^^ ^-^^^ -^^-^ communicatioL 



Each of the installations for the financial institutions 308. 309 preferably include 
a payment service enhancement package 322. Ttis package provides easy adoption of 

atd ™ -q^ement 

and short serv.ce launch time for issuing financial institutions 308 and for acquiring 
15 fmancxal mstitutions 309. The payment service enhancement package 322 integrate! 
with existmg financial institution system back-end 323 to suitably provide a fimJcey 
solution for payer authentication, message transport and value added service 
operations. 



It IS anticipated that financial institutions wiD be responsible for setting up their 
consumers on the payment gateway 301 to provide the electronic funds transfer service 
A party profile is estabUshed for each party by using the administration sub-module 
318 to store party information and acquire a unique Party ID. Existing party accounts 
credit card accounts in the embodiment, are then mapped to the party ID. The payment 
25 gateway also generates a User-Admin ID allowing the party to perform user 
administration. TTie security sever 315 is then employed to set up a sigmng matrix for 
each account and digital signatures for party approved signatories are mapped to 
specific accounts. Typically, the financial institution would forward a electronic fimds 
transfer service package containing aU relevant components to each party. 

In turn, certain set up actions on tiie payment gateway 301 must then be 
undertaken by the party on receipt of the package fi:om their financial institution. 
Individual user profiles are generated for payer personnel who are to have access to the 
payment gateway 301. Individual users are preferably assigned to user groups 
consistent with their functional responsibilities in the payer business organisation. 
Authorised signatories must activate their digital signatures through the appropriate 
trusted certificate authority 302. A party that is a business entity may establish a 
hierairchy of signatories for transaction initiation, which is preferably matrix based. 
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Each Signing authority matrix is assigned to a specific account number. TypicaUy, a 
business party would have three groups of signatories and, on average, two signatures 
required. Consider a notional account which may be operated ftom signatories from 
three user groups A, B and C as depicted in Table 1 below: 

5 



Account Number 


Group 


A 


B 


C 


self 


10 


20 


30 


A. 


40 


50 


60 


B 




70 


80 


C 






90 



Table 1 - Signing Matrix 



An individual from user group A of the account can sign for up to 10 by 
10 themselves, up to 40 with another member of group A assigned to the same account, up 
to 60 with a member from group C assigned to the account, ... etc, as illustrated above. 
The signing of electronic transactions need not be dependent on corporate and account 
mandates held at the financial institution. Separate arrangements may be defined in 
electronic business (EB) agreements that are accepted by the company governance 
15 board. 



Looking at the party end of the electronic fimds transfer system 300, a business 
portal function is provided through the web pages 311 embedded in the business hubs 
304. The portal frmctions include &cilitating creation of invoices by a payee and 
20 facilitating payment by a payer. Party computer systems 303 access the B2B hubs 304 
via the Intemet 305 using a conventional web browser 324, such as Microsoft's Internet 
Explorer™ or Netscape's Navigator™. The party browser will suitably include a smart 
card plug-in component 325, since it is desirable that the certificates and private key 
issued by the trusted CA 102 to authorised signatories are stored on a smart card. 

25 

The principle security concerns of the electronic funds transfer system 300 in its 
operation are desirably: 

ensuring the confidentiality of data transmission, 
• authenticating all parties involved in each traiisaction, and 
30 • ensuring integrity of data in transactions; 

when operating in the context of a world wide distributed environment, using the 
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L^temet and web based applications with^'e^^^^^ party connections including 
fciancid networks (such as VISANET), business hubs and financial institutions (banks 
etc.) The authenticity of Payee to Payment System and the authenticity of the Payer to 
ti,e Payee are the responsibility of the B2B hub in the present embodiment. The B2B 
5 hub Identifies the merchants with whom the payer can securely conduct electronic 
commerce. The merchant registration process eliminates the need for merchant 
authentication. Registration with the electronic fiinds transfer system ensures that the 
merchant has a relationship with a financial institution allowing it to receive electronic 
payments.. 

When the B2B hub web application 312 initiates the payment service, the Payer 
ID, Payee ID, Invoice Information and the B2B hub's Digital Signature are passed to 
the payment gateway 301. The B2B application, using the B2B hub private key. signs 
this data foUowed by encryption through a virtual private network (VPN) tunnel This 
ensures the data confidentiality and integrity during transmission. Encryption using 
B2B hub's private key also ensures non-repudiation of the information transmitted. The 
payment gateway system will decrypt the data and authenticate the B2B hub usmg the 
enclosed digital certificate with a trusted CA. 

When the payer completes and submit the payment instruction, the payment 
instruction details, and SHAl hash vnLl be encrypted using the payer's private key. The 
payer's digital certificate and the payer's private key are stored on the smart card held 
by the payer. This will ensure the non-repudiation of the payment instraction as well as 
tiie integrity of the data. The encrypted packet will be transmitted to the payment 
gateway 301 through the Internet 305 usmg SSL to ensure confidentiaKty. The security 
server 3 15 in the payment gateway will decrypt the data. 



The security server 315 will authenticate the Payer with an appropriate 
authentication authority. The authentication authority may be the issuing financial 

30 mstitution 308, the payment gateway 301 or a trusted Certification Authority (CA) 302. 
Accordingly, the electronic funds transfer system 300 ensures confidentiality and 
integrity of payment data through each and every leg of data transmission involving the 
payment system. Each piece of data is accessible only by the necessary party. For 
example, the Payer's account information will only be known by the payment gateway, 

35 Payer's financial institution. Payee's financial institution, but not by the Payee or the 
B2B hub. 



The electronic fimds transfer system 300 can implement a variety of currently 
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available protection schemes that are compliant with communications industry 
standards. The standards which the system can be configured to comply with include 
168 bit Triple-^DES, 1024 bit RSA, MD5, SHAl, X.509, 128 bit SSL v.3 and IPSec. 
Further details of these schemes can be obtained firom the relevant standards 
5 documents. 

The security deployment arrangements suitable for use with the first 
embodiment of the invention are now described in relation to FIG. 4, as follows. The 
security schemes may be implemented with a security toolkits such as Baltimore 

10 J/PKI+, which secures the following conmiunication points as illustrated in the 
drawing. The User to Trading Hub link 1 involves parties or ''users" 401 logging into 
hubs 402 to view catalogues, send purchase requests, create invoices, and to make 
payment requests. Trading hubs 402 need to authenticate a users identity either using a 
Digital Certificate or User ID and password. The basic password rules need to be 

15 enforced. A secure sockets layer (SSL) link with 128-bit encryption would be used to 
maintain the confidentiality transportation of information only when required. There is 
no need to increase load by encrypting catalogues, unless necessary. Users 401 have to 
sign on orders and invoices iising their own digital signature. 

20 The User to Payment Gateway link 2 involves transport of payment instructions 

containmg financial information. The identity of trading hubs will be authenticated by 
the payment gateway using a digital certificate. Users 401 will have to digitally sign on 
the payment instmction using digital signature scheme which may be verified through 
the Tmsted Certificate Authority (CA) 406. Java applets are used to sign data that 

25 would be transmitted. SSL v.3 would secure the transmission of the enciypted data to 
the payment gateway 403. 

The Trading Hub to Payment Gateway link 3 involves commimication of 
Payment notifications and payment approval. Hubs 402 and payment gateways 403 
30 exchange digital certificates in tiie data message for authentication. Secure 
commimications between both parties using end-to-end link encryption or virtual 
private networks (VPNs), together wifli hash ftmctions if required. 

The Payment Gateway to Payment Gateway link 4 involves Pajrment 
35 instructions containing financial information. Secure communications between both 
parties 403, 404 using end-to-end link encryption over leased line. 

The Payment Gateway to Financial institutions . link 5 ^ involves Payment 
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"^ons conW„ix,g financial infonnation. Secu« conununioation. 
(VPNs), together with hash functions. 

5 "^^^^J^^^t Gateway to Trusted CA link 6 involves fetching of public keys fo^ 

decryption. This link has no security risks as public keys are pubUc infonnation. 

"^^P^y^^ent Gateway to VISAI^ link 7 involves data containing VISA Base 
I and n messages. Authentication gateways would have Station IDs issued by VISA for 
Identification. Secure communications with VISAJgET 407 is via the Visa access noint 
(VAP) interface. 

In order to assist further understanding of the invention,- a schematic diagram of 
a second embodiment of the electronic funds transfer system of the invention is 
Illustrated in FIGs 5A and 5B. The system 500 provides a highly reliable and 
predictable sen'ice for mission critical business to business payments. The operation 
will withstand high volume on-lme transaction on a continuous 24x7x365 basis. The 
transaction processing volume capacity of the system of the second embodiment is 
esnmated at 1.8 million per day. The web hit rate is estimated at 300K per day. 

Given the high volume expectation of electronic funds transfer business and the 
dynamic of volume growth of Internet related operations, the main payment factory 
application component will be operated using a first fann of servera 510, such as 4 Sun 
Enterprise 4500 Servers with 14 CPUs, each with 30TB of storage capacity. The server 
tei 501 will be inter-connected using a high-speed switching hub with high 
bandwidth back plane and communicate with the database 502 and GSM-SMS/e- 
mail/fex channel servers 503 via a closed loop circuit 504. 



30 Similarly a second fenn of web servers 510, such as Sun Enterprise 450 Servers, 

can cater for the demands of Internet traffic, together wifli a wireless ^plication 
protocol (WAP) server 511 which are coupled to the Internet via a pair of firewall 
servers 512 and a pair of high performance routers 513, such as those produced by 
Cisco. Also included is an e-mail server 514, a virtual private network (VPN) server 

35 515, a certification au&ority server 516 (for use by financial institutions) and a key 
management server 517. The web server farm 510 is coupled to the payment factory 
server farm 50 1 by a further pair of firewall servers 508. 
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Financial institution host systems 520 may be coupled to the electronic 
fimds transfer system 500 via service enhancement package systems 521 through a 
VPN gateway sender and the Internet (see FIG 5 A) or directly to the closed loop circuit 
504 (see FIG. 5B), as required. 

To ensure the system's ability to scale its system to match the capacity growth, 
two strategies are essential. First employing a platform with an upgrade path for higher 
processing and storage capacity, and secondly providing a server farm configuration 
supported, with corresponding ^plication architecture, application functions and 
database partition design. The application architecture and application functions design 
will support proper load balancing and co-ordination of function execution distributed 
on multiple servers accessing different partitioned database. The database is expected 
to be partitioned based on grouping of issuing fmancial institution. 



^ procedure for monitor the system performance and capacity usage to project 
future capacity requirement is desirable. The system will typically consist of a large 
nmnber of interconnected capacity elements including processing elements, I/O 
elements, network elements and storage elements. The complexity of the overall system 
capacity model demand that a capacity planning and simulation tool be used. A highly 
20 automated system management and monitoring application is desirable to ensure 
efficient, reliable and consistent system operation to meet the high volume and mission 
critical demand of the systems operations. 



The large number of processing and other system components employed by the 
25 system 500 dictates that automated system management and monitoring is important. A 
partial light out operation will be the goal. Cross border monitoring and management is 
required in view of the geographical distributed but tightly integrated operation facihty 
that is required for a global payment service. A set of multiple system management 
and monitoring tools, such as Tiyoli, may be used as the firamework and central console 
30 for integrating the systems. A commxmications management tool, such as HP 
Openview supplied by Hewlett Packard Corporation, will be the central control and 
monitoring tool for the network components of the system of the embodiment. 

Sim Management Server, BMC tools and a suite of component specific tools can 
35 cover management and monitoring of the rest of the system components including tools 
for Oracle 8i database. Sun's Solaris operatiag system, Web server, storage system, 
system security, job control, application, change management, network performance 
monitoring/management, application performance monitoring^management, and 
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availabiUty management of applications and services. The monitoring tools can 
track the component and system perfonnance against baseline, identify faults and 
anticipate eminent failure. Tracking data, warning and alerts may be delivered to the 
relevant parties through e-mail via the corporate e-mail gateway 505, paging/SMS 506 
and fecsimile 507. The automation will aUow opemtois of the system to pre-empt 
problems and recover from faUures in the shortest possible time. 

Although an illustrative embodiment of the present invention, and various 
modifications thereof have been described in detail herein with reference to the 
acconipanying drawings, it is to be imderstood that the.invention is not limited to this 
precise embodiment and the described modifications, and that various changes and 
fiuther modifications may be effected therein by one skilled in the art without departing 
from the scope or spirit of the invention as defined in the appended claims. 
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CLAIMS 

1. A method of efifecting an electronic transfer of funds between a payer account 
and a payee account wherein the payer account and the payee account are each held by 
respective parties at financial institutions associated with a financial settlement 
5 network, said method including the steps of: 

(a) a payer providing a purchase order to a payee, which purchase order 
identifies the payer to the payee; 

(b) . a payee, subsequent to receipt of the purchase order, providing an invoice 
to the payer, which invoice identifies the payee account for crediting funds in the 

10 transfer, 

(c) the payer, in response to receipt of the invoice and subsequent to approval 
of the transfer, transmits a secured pajment instruction to a payment gateway, which 
payment instmction identifies the payer account for debiting; 

(d) the payment gateway, in response to receipt of the seciired payment 
15 instruction and subsequent to ensming authenticity of the payment instruction, creates a 

payment request message for the payer's financial institution and passes the payment 
request to the financial settlement network; and 

(e) the payment gateway, in response to a payment authorisation message 
from the payer's financial institution, notifies payment approval to the payer and passes 

20 a settlement message to the financial settlement network, whereby the settlement 
network facilitates settlement of the funds transfer on a net basis with the payer's 
financial institution and the payee's financial institution. 

2. The method of claim 1 wherein the payer transmits the purchase order to the 
25 payee via a business hub. 

3. The method of claim 1 wherein the payee transmits the invoice to the payer via a 
business hub. 

30 4. The method of claim 1 wherein parties are each allocated a unique identifier that 
is registered with the payment gateway. 



5. The method of claim 4 wherein the unique identifier for a party is desirably 
registered with the payment gateway in relation to at least one account with a financial 
35 institution. 
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6. The method of claim 5 Wherein a party may register a merchant account for 
sellmg purposes and/or a debit account for buying purposes. 

7. The method of claim 6 wherein the debit account is associated with at least 
signatory registered with a trusted authority for security purposes. 
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8. The method of claim 1 wherein financial institutions are each aUocated a unique 
identifier that is registered with the payment gateway. 

10 9. The method of claim 4 wherein the purchase order includes the payer's party 
Identifier and a description of the goods and/or services desired to be purchased. 

10. The method of claim 6 wherein the payer creates a payment instruction by 
accessmg a business hub. selecting the payer account from the debit accounts registered 

15 with the payment gateway and selecting the desired currency and amount for payment 

11. The method of claim 1 0 wherein, in the case of a foreign currency payment, the 
payer selects a foreign exchange rate from a board rate specified by the financial 



institution. 



12. The method of claim 7 wherein an approved signatory applies a security means 
to the payment instruction prior to transmission to the payment gateway. 

13 The method of claim 12 wherein payers maintain a signing matrix of approved 
25 signatories on the payment gateway for each registered debit account. 

14. The method of claim 13 wherein the step of ensuring authenticity of the 
payment instruction includes the payment gateway checking the security means against 
the approved signatories for the registered debit account 



15. The method of claim 1 wherem the payment request is created by reformatting 
the information contained in the payment instmction, including the payer account and 
an identifier corresponding to title payer's selected financial institution. 



16 The method of claim 1 wherein the pa5nnent request is an SMS 0200 financial 
transaction request message that is sent to the financial settlement network which 
includes a credit card settlement network. 
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17. The method of claim 1 including the further step of: 
(g) notifying the payer upon settlement of the transfer. 

18. The method of claim 1 wherein the credit card settlement network facilitates 
5 settlement of the . funds transfer on a net basis for both domestic and international 

transactions through a settlement financial institution. 

19. The method of claim 1 wherein an agent financial institution facilitates foreign 
cmrency settlement with the payer's financial institution and/or the payee's financial 

10 institution. 

20 An electronic funds transfer apparatus for effecting transfer of funds between a 
payer account and a payee account wherein the payer account and the payee account 
are each held by respective parties at financial institutions associated with a financial 
15 settlement network, said apparatus comprising: 

(a) a payment gateway having a payment web server and a payment factory, 
wherein the payment web server commimicates with the parties and the payment 
factory communicates with the financial settlement network; 

(b) the payment web server is operative to provide payment services to 
20 parties, wherein payers transmit secured payment instructions to the pajmient gateway 

subsequent to receipt of invoices provided by payees, which invoices identify the payee 
accoimt for crediting; and 

(c) the payment factory is operative to process said secured payment 
instructions, which instructions identify the payer account for debiting, by creating 

25 messages for the credit card settlement network requesting authorisation of payment 
firom the payer account and facilitating settlement of the fiinds transfer on a net basis 
with respective financial institutions of the payer and the payee. 

21. The electronic funds transfer apparatus of claim 20 wherein the payment web 
30 server includes an integrated module for offering payment services to payers and 
payees via at least one business hub. 

22 The electronic funds transfer apparatus of claim 21 wherein the invoices are 
transmitted by payees to payers via said at least one business hub. 



35 



23. The electronic funds transfer apparatus of claim 21 wherein the pajnnent web 
server includes a security arrangement for securing information supplied to said at least 
one business hub. 



wo 02/11089 



24 



PCT/SGOl/00153 



24. The electronic fimds transfer apparatus of claim 23 wherein th. 

Lrrr ^"^'^'^ ^ '-^'^ ^^^^^^ ^for.^Zr.tz^:::zi 

account, the payee account and the fimds for transfer. 

H ''''' "^^^ "^'^^ "PP^*^ ^^'^^^ 20 wherein the payment fectorv 

^udes a. adnxnaistration module for registering parties that wish toX^^ 
tiHnsfers. by allocatuig a unique identifier to each party. 

26 The electronic fia.ds transfer apparatus of claim 20 wherein the payment factorv 
mcludes a payment engine for processing the secured payment ins^ction^I^ 
inessages lormatted for the* finanr^i'a] 



27. 



The electronic fimds transfer apparatus of claim 21 wherein the payment web 
15 server communicates with said at least one business hub and with registeredT^es ^a 
a public communications network- 

28^ The electronic fimds transfer apparatus of claim 20 wherein the payment factory 
fiirther mcludes interface means for commmiicating the authorisation request messages 
20 and settlement messages to the financial institutions via the fmancial settlement 
network. 

29. The electronic fimds transfer apparatus of claun 23 wherein the fmancial 
settlement network includes credit card networks. 

25 

30. The electronic fimds transfer apparatus of claim 20 wherein the payment fectoiy 
further mcludes a secmity server for authenticating said communications using 
predeterrmned securing means. 

30 3 1. The electronic fimds transfer apparatus of claim 20 wherein the predetermined 
securmg means for communicating via the public communications network includes 
digital certificates and private keys allocated by a trusted authority. 

32. The electronic fimds transfer ^paratus of claim 20 wherein the financial 
35 settlement network transmits settlement messages at least daily to financial institutions 
in the network. 
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